Skip to content

test: integration tests can now call dynamic libraries#1690

Open
ostylk wants to merge 1 commit intowild-linker:mainfrom
ostylk:push-ntlnsyyuosmx
Open

test: integration tests can now call dynamic libraries#1690
ostylk wants to merge 1 commit intowild-linker:mainfrom
ostylk:push-ntlnsyyuosmx

Conversation

@ostylk
Copy link
Contributor

@ostylk ostylk commented Mar 13, 2026

Implements #1687 .

Using //#RunDynSym:foo the output binary is treated as a shared library and loaded into the current test process.
The function foo needs to return an integer and it succeeds if it returns 42.

Cross compiled libraries cannot be tested that way.

Is there one test in particular where you want to use this feature? I enabled it for shared.c and called foo().

.with_context(|| format!("Invalid Mode `{arg}`"))?;
if mode == Mode::Dynamic {
config.assertions.expect_dynamic = true;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, specifying //#Mode:dynamic implicitly sets //#RunEnabled:false (introduced in #1033), so I think this needs to be corrected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that has been reverted in b88576e ?

@ostylk ostylk force-pushed the push-ntlnsyyuosmx branch from a178060 to 4c28c32 Compare March 14, 2026 09:54
@davidlattimore
Copy link
Member

Thanks for doing this!

From a quick look at the test failures, there seem to be two causes. Tests fail on Alpine. Alpine uses musl libc. Although musl libc supports dynamic linking, it's possible that this isn't happening. dlopen doesn't work with statically linked binaries. Probably the easiest option would be to skip the test if RunDynSym is set and is_musl_used returns true.

The other failures look like they're from trying to use qemu to run the binary. It'd be possible to support this, but we'd need to have the test framework compile an executable for the target arch where that executable loaded the shared object, ran it, then exited with the appropriate code. This could perhaps be done as a follow-up. For now, I'd probably suggest just skipping cross-compilation tests when RunDynSym is set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for loading and running shared objects to test framework

3 participants